home *** CD-ROM | disk | FTP | other *** search
/ Atari Mega Archive 1 / Atari Mega Archive - Volume 1.iso / lists / mint / l_0799 / 733 < prev    next >
Encoding:
Internet Message Format  |  1994-08-27  |  1.6 KB
  1. From: ekl@sdf.lonestar.org (Evan K. Langlois)
  2. Subject: file systems
  3. Date: Wed, 29 Dec 93 2:24:44 CST
  4.  
  5. I've been gone for awhile, so if this stuff has already been talked 
  6. about - forgive me.
  7.  
  8. Anyway, I noticed that loaded file systems return a -33 and not a -34
  9. when a non-existing path is accessed.  I haven't seen a fix in th 1.09
  10. diffs, but its definately a bug (its also why STZIP doesn't create folders).
  11.  
  12. Now, I looked at the MiNT code, and decided that didn't help since it
  13. looked fine.  I looked at the ramfs code, and noticed that the "lookup"
  14. function that "relpath2cookie" was calling didn't differenciate between
  15. a directory or a file.  So, when the name wasn't found, it returned -33,
  16. and I would assume that minixfs does the same thing (since it too returns
  17. -33 instead of -34 from the relpath2cookie call).  Now, what I'd like to
  18. know, is how the filesystem can determine if the name its looking for is
  19. a directory or filename?  And if it can't then shouldn't the MiNT kernel
  20. change a -33 (EFILNF) to -34 (EPTHNF) when the name being looked-up is
  21. a directory?
  22.  
  23. Also, before my absense everyone seemed to be talking about the Fseek
  24. differences.  All the filesystems seem to handle it differently.  The
  25. procfs has some stuff changed I think, but in any case, ramfs code or stzip
  26. needs to be changed (was this already done?  Which way is correct?)       
  27.  
  28. As an aside, someone mentioned a multi-screen program for MiNT.  Will this
  29. work remotely?  And is there is a decent remote login package for MiNT?
  30. I have one but it doesn't work right at all and I'm too lazy to fix it.
  31.  
  32. Thanks,
  33. Evan Langlois
  34.  
  35.  
  36.